feat: increase background stop debounce time - #1146
Open
jvsena42 wants to merge 3 commits into
Open
Conversation
Greptile SummaryThis PR extends the Lightning node’s background-stop debounce from three to five seconds to avoid unnecessary teardown and restart during brief app switches.
Confidence Score: 5/5The PR appears safe to merge, with the timing update remaining within the documented freezer window and existing atomic cancellation behavior preserved. The change only extends an already-tested debounce constant and updates its assertions and documentation; no concrete blocking or non-blocking defect remains.
|
| Filename | Overview |
|---|---|
| app/src/main/java/to/bitkit/repositories/LightningRepo.kt | Increases the existing background-stop delay to five seconds and documents its lifecycle constraints without changing scheduling or cancellation semantics. |
| app/src/test/java/to/bitkit/repositories/LightningRepoTest.kt | Updates the shared expected debounce duration while retaining boundary and cancellation coverage. |
| changelog.d/next/1146.changed.md | Accurately describes the user-visible benefit of retaining the Lightning node during brief app switches. |
Reviews (1): Last reviewed commit: "doc: changelog" | Re-trigger Greptile
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR raises the background stop debounce from 3 to 5 seconds, so a brief trip out of the app no longer tears down and rebuilds the Lightning node.
Description
When the app is backgrounded without the foreground service keeping it alive, the node stop is deferred so a quick background/foreground cycle does not tear it down. Three seconds is short enough that ordinary interruptions — checking a notification, copying an address, fetching a 2FA code — fall outside the window and pay for a full teardown and rebuild.
The ceiling on that window is Android's cached-app freezer, not any API limit. Once the process drops to
oom_adj900 it is frozen after roughly ten seconds, and a frozen process cannot run the pending stop at all: it would fire on unfreeze instead, racing the cancel that runs when the app returns to the foreground. Because the stop runsNonCancellable, losing that race tears the node down exactly as the user comes back. Five seconds sits comfortably inside that window while covering meaningfully more of the short interruptions the debounce exists for.Device testing also showed the cost of a teardown is far higher than assumed. On a wallet with real payment history the node stop takes a flat 30 seconds and ends by hitting ldk_node's own event-handling deadline, after which the rebuild takes another eight. A user who returns mid-stop waits that out before the wallet is usable again, which is what makes avoiding an unnecessary teardown worth the longer window.
That 30-second timeout is pre-existing and independent of this change — the debounce only decides when the stop begins, not how long it takes — but it is worth a separate look, since every background cycle on a real wallet now burns 30 seconds of the LDK queue and exits through an error path.
The KDoc on
stopDebouncedrecords the freezer ceiling so the value is not later raised past it.Preview
No UI changes.
QA Notes
Manual Tests
regression:Notifications granted and keep-active-in-background enabled → background the app: foreground service keeps the node alive, no stop occurs at all.regression:Background the app → return mid-restart: no crash, wallet settles into a usable state.Automated Checks
LightningRepoTest.kttracks the new 5s value; its boundary assertions still pin that the stop does not fire just before the window and does fire at it.freezer_cutoff_adj=900,freeze_debounce_timeoutunset so the AOSP 10s default applies; the process was observed frozen 8.79–9.34s after dropping to cached.Journey used for testing
All seven actions passed. Leg 1 confirmed the node is never stopped inside the window; leg 2 confirmed a clean stop and restart past it.
Logs: debounce fires at 5s, inside the window (leg 1)
Returned 2.0s after backgrounding. No
Stopping node…entry — the node was never torn down. The event listener cancel and restart 15ms apart is the normal foreground re-subscribe.Logs: debounce timing across four runs on a 137-payment wallet
Logs: pre-existing 30s stop timeout surfaced during testing
30.014s / 30.022s / 30.030s / 30.047s across the four runs — a flat deadline rather than load-dependent variance. Against a near-empty wallet the same stop took ~0.5s, which is why this only appears with real payment history. Independent of this change; flagged for separate follow-up.